Computer automated control systems often send control messages across a network to actuate controlled apparatuses in those networks. Moreover, frequently a large number of scheduled event messages are retrieved from a data storage device and transmitted across such a network in a short period of time. For example, if lights are to be energized or de-energized at a scheduled time, scheduled event messages may be read for each lighting fixture or bank of fixtures that are controlled together. In addition, an operational control message may be sent across the network to each lighting fixture or bank of fixtures that are controlled together to actuate the lights scheduled to be energized or de-energized. In a large building where many areas, such as lobbies and common areas, are to be lit at one particular time, many scheduled event messages may be read and many control messages may be sent across the network at a time or during a short period of time.
When a large, mesh-networked system is managed and controlled by, for example, a resource-limited, single flow embedded processing system, inefficiencies can arise that impact overall system performance and user experience.
Inefficiencies in such a system may occur when a large number of messages are being sent over the network. When too many messages are sent across the network, the network may become congested and operate inefficiently, message delivery may be delayed, network queues may overflow, thereby losing messages, messages may otherwise be lost and fail to be delivered by the network as required, and users may experience delays or failures in system operation.
There exists a layer of software in many networking systems that manages the transmission and receipt of messages. For example, a ZigBee or Bluetooth software stack is a layer of software that sends and receives messages, including unicast messages (directed to a single device) and broadcast messages (directed to one or more devices). Since broadcast messages are generally sent to more than one device, it is common in a mesh network for a broadcast packet to be re-broadcasted (or repeated) by multiple nodes to ensure all nodes in the system receive the packet. Having multiple nodes re-broadcast each broadcast packet helps ensure that all devices in the network receive the broadcast packet.
Each broadcast packet has high overhead due to the multiple transmissions that can result as multiple nodes re-broadcast each packet. For example, to avoid re-sending a broadcast packet too many times, each node must typically track which broadcast packets it has re-transmitted, often using a broadcast table to store information relevant to each repeated transmission. A broadcast table retains this information for a certain time. The size of the broadcast table limits how many concurrent broadcast packets a device can send and monitor. If the broadcast table is full on a node such that all entries in the table are storing information for broadcast packets, then that node will not be able to store information for any additional broadcast packets until an entry is made available in the table.
Due to limitations in the size of a broadcast table, it is possible for an application to attempt to transmit more broadcasts than can fit in the table. This can lead to having broadcast packets not be received by all devices, or having the broadcast packets be sent in unpredictable bursts over time. For example, if a node has 15 entries in its broadcast table, and there are 8 broadcast transmissions already taking place such that 8 of the 15 entries are being used, and if a device needs to send 10 additional transmissions, then 7 of the 10 new messages could be sent immediately, while the other 3 might be sent at a later time when there is room in the broadcast table. This delay could take many seconds—possibly on the order of 8 or 10 seconds. Of course it undesirable if 7 of 10 commands are sent immediately, and 3 are sent 8 seconds later or are not transmitted at all.
Thus there is a need for systems, apparatuses, and methods to prevent a significant delay between the receipt of first messages and the receipt of second messages that are to be executed concurrently with the first messages.
There is also a need for systems, apparatuses, and methods that provide a delay in sending messages across a network when many messages have recently been sent across that network.
Embodiments of network traffic management apparatuses, systems and methods minimize any delay between the receipt of first messages and second messages that are to be executed concurrently
Embodiments of network traffic management apparatuses, systems, and methods delay sending messages across a network when many messages have recently been sent across that network.
Embodiments of network traffic management apparatuses, systems and methods distribute the transmission of messages to be sent at a particular time to prevent loss of transmitted messages or other problems that can occur when many messages are sent at or near the same time.